home *** CD-ROM | disk | FTP | other *** search
- Path: news.Stanford.EDU!not-for-mail
- From: brien@leland.Stanford.EDU (brien oberstein)
- Newsgroups: comp.lang.c++
- Subject: Re: Copy constructing an already default constructed object
- Date: 27 Jan 1996 10:33:13 -0800
- Organization: Stanford University
- Message-ID: <4edr59$87h@elaine11.Stanford.EDU>
- References: <4e906b$stk@elaine32.Stanford.EDU> <4eal0n$hgq@dawn.mmm.com> <3108ef14.340699@nntp> <4ebehj$5i7@news.bridge.net>
- NNTP-Posting-Host: elaine11.stanford.edu
- X-Newsreader: NN version 6.5.0 (NOV)
-
- David Byrden <100101.2547@compuserve.com> writes:
-
-
- >>> A::operator =(const A& other)
- >>> {
- >>> b0 = other.b0 ;
- >>> b1 = other.b1;
- >>> }
-
- >>> To me this seems like a major pain in the butt.
-
- >That's precisely why the compiler will automatically generate a public
- >assignment operator with this behaviour, if you don't bother to write
- >one.
-
- Bzz. Try again king shit. The compiler generates memberwise assignment.
-
-
- >>> Do you have to overload = for all the contained operators too?
-
- >>> All I really want to do is have the copy constructor invoked on the
- >>> piece that piece of memory. Why can't this be done?
-
- >Brien, I genuinely cannot understand what you are trying to say in these
- >two sentences. Sloppy English, like C++, can be a "major pain the the
- >butt".
-
- Dave, I hereby BAN you from reading this thread any further. This is for
- your own good. Dave, you are forbidden from reading my articles anymore.
- Its obviously too stressful for a guy like you. Genuinely understand that.
-
- -brien
-
- PS If I ask for the toilet paper then you can roll out.
-
-
-